The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.
Various technologies have recently been developed to link a smartphone with a vehicle head unit or an audio video navigation (AVN) system installed in a vehicle.
For example, a smartphone manufacturer, Apple and an Android OS provider, Google have recently launched CarPlay and Google Android Auto, respectively, corresponding to individual standards. As a result, a user can use a display of a vehicle head unit through a second display of a smartphone by connecting the smartphone, which has iOS or Android OS, to the vehicle head unit by wire.
In addition, application of MirrorLink solution led by the Car Connective Consortium has been gradually extended by several original equipment manufacturers (OEMs). In China, a function of linking a vehicle AVN system and a smartphone has been individually standardized by leading information technology (IT) companies such as Baidu, Tencent, etc., and the function has been developed.
The function of linking the vehicle AVN system and the smartphone allows various applications of the smartphone to be conveniently used in a vehicle, allows applications suitable for the vehicle to be distributed through the ecosystem previously constructed by Apple/Google/Baidu, etc., and allows the applications to be frequently updated. Thus, it is possible to effectively overcome problems of the absence of the ecosystem, restriction on upgrade and connection, etc. that a conventional vehicle has had. Therefore, the function of linking the vehicle AVN system and the smartphone is expected to be a technology that can complement marketability of a vehicle AVN system which can lag behind a conventional IT product.
However, a currently released function of linking a vehicle AVN system and a smartphone has been generally developed such that a standard technical specification of each company is satisfied by distributing a software (SW) plug-in which operates in the vehicle AVN system by Apple/Google, etc. and mounting the SW plug-in in the vehicle AVN system even though the function is different between respective implementation entities.
However, when the function of linking the AVN system and the smartphone, which is different from a basic function of the AVN system, is implemented, the functions may collide with each other. In addition, when the SW plug-in distributed by Apple/Google, etc. is applied to the AVN system, there is a problem of many errors due to different internal configurations.
Moreover, when code is counterfeited or falsified by a malicious hacker in a process of distributing SW of Apple/Google, etc., there is a more serious problem in that code having a potential security risk is installed in the AVN system, and thus vehicle security risk increases.
As illustrated in FIG. 1, according to a current technology of linking a smartphone and a vehicle AVN system, the smartphone and the vehicle AVN system are connected to each other using a physical communication means such as a universal serial bus (USB) or Wi-Fi, and the vehicle AVN system decodes, renders, and outputs received data such as video or audio when the smartphone transmits the data. In addition, the vehicle AVN system may transmit, to the smartphone, input data input through an included input means such as a touch screen, a key button, etc., audio data for voice recognition, handoff, etc., positioning data acquired through a global positioning system (GPS) module included in the AVN system, etc.
However, current individual standards of IT companies such as CarPlay of Apple and Android Auto of Google are implemented only using documents provided by the respective companies, and thus may not be applied to the vehicle AVN system. As such, the SW plug-in that operates by being mounted in the AVN system has been provided other than a basic technical specification. A vehicle developer has been implementing the function of linking the vehicle AVN system and the smartphone by installing the SW plug-in in the AVN system and connecting the SW plug-in to an application layer. FIG. 2 illustrates a hierarchical structure of a conventional AVN system implemented to provide the function of linking the vehicle AVN system and the smartphone. As illustrated in FIG. 2, a smartphone linkage application mounted in the conventional AVN system has shared an OS and a hardware resource in addition to middleware and a user interface framework with an AVN application without a separate restriction. Therefore, there has been a problem in that, when the OS malfunctions due to the smartphone linkage application, the AVN application cannot be used either. In addition, there has been a problem of poor security in a vehicle since the smartphone linkage application shares a hardware resource such as a controller area network (CAN) without a separate restriction.
In particular, referring to the function of linking the vehicle AVN system and the smartphone, due to different characteristics between the smartphone which puts emphasis on convenience/availability and the vehicle which puts emphasis on safety, respectively, vehicle safety may be endangered if the smartphone linkage application shares AVN hardware without a separate restriction even when the vehicle requires a higher level of safety than the smartphone.
For example, while the smartphone functions as a guide, the smartphone may abruptly crash and not function or abruptly malfunction while making a strange noise, or a whole screen may become black and not be restored. More seriously, the OS of the AVN system may be in an unrecoverable state, and may not operate until a driver restarts the vehicle. The driver may be distracted due to these problems during driving, which may be fatal to safe driving.